Digital Subscriber Line (DSL) technologies are a family of high-speed access technologies using ordinary telephone lines. One of these DSL technologies is Asymmetric Digital Subscriber Line (ADSL). ADSL is characterized by a different data rate from the service provider to the customer premises (downstream) as compared to the data rate from the customer premises to the service provider (upstream). Data rates are typically 10 times higher in the downstream direction (compared to the data rate in the upstream direction), which are suitable for applications such as in Internet access. However, other ratios of downstream to upstream rates are also used. For example, voice delivery over ADSL uses symmetric data rates (i.e. same data rate in downstream and upstream direction) while video delivery over ADSL is highly asymmetric and uses as much as 100 times higher downstream than upstream rates. ADSL shares the same line as the telephone but uses a higher frequency band than the voice band. A POTS (Plain Old Telephone System) splitter on the customer premises equipment is used to separate the voice and ADSL signals. ADSL is geared to the consumer market. The standard ADSL technology uses Discrete Multitone (DMT) modulation. The transceiver may carry more than one data channel and may also carry an embedded operations channel (EOC), an ADSL overhead channel (AOC), and also various other bits. The physical ADSL link carries more than one logical channel, where a logical channel is defined as a data or an overhead channel. The logical data channels or bearer channels on the ADSL link consist of four possible simplex downstream channels and three possible full-duplex channels. The simplex channel is commonly used as the downstream channel. The duplex channels may have different upstream and downstream rates and may be used in the simplex mode for upstream transmissions. ADSL has a superframe structure made up of N data frames with the (N+1)th frame being a synchronization symbol or sync frame. For ITU-T G.992.1, ITU-T G.992.2, and TIA/ANSI T1.413 standards we have N=68. Each data frame contains a specified number of bytes for each of the logical data channels. The interleaved path contains an interleaving function in the transmitter and the fast path does not. Overhead bytes are also contained in each data frame. The overhead bytes contained are different for different frame numbers. Each data frame is divided into a fast buffer part for data to be sent via the fast path and an interleaved buffer part to be sent via the interleaved path. The overhead bytes consist of messages in the EOC and AOC channels as well as bit level indicators. In a dual-latency configuration, the EOC is carried in the fast byte of the fast channel. The ATU-C (modem located at the central office) uses the EOC messages to retrieve information from and to send information to the remote ATU-R (remote). The AOC channel allows for a process known as bit swapping in which a bit is removed from one carrier (causing a constellation to become smaller) and is placed onto another carrier (causing its constellation to become larger). AOC messages can be carried in either the sync byte of the interleaved channel or the LEX byte of the interleaved channel in a dual-latency configuration. LEX byte is inserted in a transmitted ADSL frame structure to provide synchronization capacity that is shared among various channels. In a single-latency configuration, both the EOC and AOC are carried in the same (fast or interleave) channel. For each superframe, 24 indicator bits are sent using an overhead byte in frame 1, frame 34 and frame 35. These bits indicate the per ATU anomalies that have occurred during the preceding superframe. These anomalies include whether or not the Forward Error Correction (FEC) had to correct any bytes during the previous superframe, whether or not a loss of signal (LOS) occurred during the last superframe, and whether a remote default indication (rdi) is present.
A problem with current G.dmt standards and G.lite standards for ADSL modems is that a fixed and sometimes excessive data rate is allocated to the frame overhead channel. This not only results in reduced available payload data rates but also in reduced reach of ADSL modems. Both represent obstacles for wider deployment of ADSL technology. The ability to effectively reduce the data rate of the frame overhead channel makes a higher payload data rate available and increases the reach of ADSL modems. It is highly desirable to provide a way of reducing the overhead data rate and decoupling the overhead channel transmission from the payload data transmission.
Two different proposals for framing of the overhead channel have been presented. The first proposal uses one Sync Byte per MUX Data Frame (MDF) to carry the overhead channel. This proposal has the advantage of being very similar to the framing of the overhead channel in the G.992.1 standard, but it also has the following issues:
When no fast (i.e. non-interleaved) path is available (as is the case in interleaved, single-latency mode), the overhead channel is interleaved and end-to-end transmission delay cannot be guaranteed. The term “latency” refers to end-to end delay of data transmission from the transmitter (for example, central office ) to the receiver (the user, for example). The latency in the fast path is smaller than that of the interleave path. A DSL connection can be trained to have only one of the two latency paths, resulting in a single-latency mode. It can be trained to have both the fast and the interleave path, resulting in a dual-latency mode. Future standards may also support multiple latency paths beyond just two. The fact that this end-to-end transmission delay on the interleave path cannot be guaranteed may be unacceptable for the transmission of time sensitive Indicator Bits identified in a proposed standard (including Loss of Power indication). A solution is to open the fast path specifically to transmit the overhead channel in the Sync Bytes of the fast path. (This is already done in current ITU-T G.992.1).
Since the overhead channel is carried in the Sync Bytes and the Sync Bytes are tied to the MUX Data Frame(s), the frame overhead rate is tied to the net data rate in the same latency path through the relation:
      Net    ⁢                  ⁢    Data    ⁢                  ⁢    Rate              ∑      i        ⁢          B              p        ,        i            where i indexes the frame bearers (i.e. channels) and p denotes the latency path. As a result, it is not possible to keep the frame overhead rate (even approximately) constant while changing the net data rate (in the same latency path) through a new mode known as Seamless Rate Adaptation (SRA) that is proposed for next generation ADSL standards.
In multiple latency mode, the bit-oriented and the message-based overhead structure may be both carried in the overhead channel of one latency path while only the cyclic redundancy check (CRC) and some path-related Indicator Bits are carried in the respective overhead channels of all other latency paths. While the CRC covers 68 MUX Data Frames (containing 68 Sync Bytes), only two out of the 68 available Sync Bytes are actually used in those latency paths (i.e. one Sync Byte is used for the CRC, the other Sync Byte for the path-related Indicator Bits). In other words, 97% (i.e. 66/68) of the frame overhead rate remains unused on the additional latency path(s). Unused bandwidth on long loops at small available line rates is undesirable and this counters the objectives of next generation ADSL standards (G.dmt.bis and G.lite.bis).
The second proposal moves the overhead channel into a separate latency path and thus achieves a separation of the frame overhead data rate from the next data rates in all latency paths. That is, changing any net data rate will not affect the frame overhead rate as long as LOH (i.e. the number of overhead bits per DMT symbols) is kept constant. This proposal has the following issues:
Since the bit-oriented and the message-based overhead structure are both carried in the separate overhead path, only the CRC and some path-related Indicator Bits are carried in the respective overhead channels of the latency paths. Now the same issue arises as described above, that is, 97% of the frame overhead rate remains unused per enabled latency path.
To achieve a lower frame overhead rate, the proposal suggests fractional values for M (i.e. the number of MUX Data Frames per Reed-Solomon codeword). However, since the CRC covers 68 MUX Data Frames, still only two out of 68 available Sync Bytes will be used for CRC and path-related Indicator Bits. As with integer M, 97% of the frame overhead rate remains unused.